Fixes #3746

A note before the technical stuff: I understand if this isn't code you want to merge — it touches your effect patch and you probably have your own plans for the connection layer. I mostly wanted to write down where I found this problem can be fixed, because the disconnect loop still exists for me on the latest nightly, and it makes working on a remote machine over LAN really rough. I built this patch and ran it locally, and it fixed the problem on my setup (details below). If you'd rather solve it differently, I hope the analysis at least saves someone the digging. Happy to adjust anything.

Symptom

Since 0.0.28, connections to a remote server constantly drop and reset. Users see the "connecting…" overlay appear mid-work (blocking the composer), often followed by "… did not respond during connection setup." On 0.0.27 the same setups are stable. It affects both direct LAN connections and SSH-tunneled ones, and it's worst when the host machine is under load (in my case a Windows 11 host; the mechanism itself is platform-independent, but hosts that stall longer — AV scanning, slower process spawning, heavy agent turns — hit it far more often, which may be why it's less visible in local Mac development).

Root cause

I bisected the 0.0.27 → 0.0.28 range. The behavior change comes from the connection architecture rewrite in #2978, via an interaction with effect's built-in socket heartbeat:

• RpcClient.makeProtocolSocket has a built-in heartbeat with defaults of ping every 5s, pong deadline 5s. If a pong doesn't arrive within 5 seconds, the socket is failed with SocketError("ping timeout"). Neither the old nor the new code overrides these defaults.
• Before (0.0.27), wsRpcProtocol.ts created the protocol with retryTransientErrors: true and an exponential retry policy, so a ping timeout was healed inside the protocol layer: the socket silently reconnected and in-flight requests were retried. Users never saw a 5-second stall.
• After (0.0.28), rpc/session.ts creates the protocol with retryTransientErrors: false, retryPolicy: Schedule.recurs(0), and reconnection ownership moved (deliberately, and reasonably) to the connection supervisor. But the supervisor's unit of recovery is the whole session: any socket failure → onDisconnect → full teardown → re-establish socket + initial sync, under the supervisor's 15s CONNECTION_ESTABLISHMENT_TIMEOUT, with the blocking "connecting…" UI.

So the net effect of the rewrite is that a single pong arriving later than 5 seconds — previously invisible — now tears down and rebuilds the entire session. A busy server event loop (long agent turn, git operations, file watching) or a latency spike on the tunnel is enough. And if the host is still busy during re-establishment, the 15s setup deadline also fails, producing exactly the "did not respond during connection setup" error from #3746, and the cycle repeats — the constant "reset, reset, reset" users report.

The server side is not involved: RpcServer only answers pings, it never enforces a deadline on clients, so this is fully addressable client-side.

The fix (smallest change I could find)

Two parts:

1. Pass pingInterval: "10 seconds", pingTimeout: "20 seconds" to makeProtocolSocket in packages/client-runtime/src/rpc/session.ts.
2. Extend the repo's existing effect patch (patches/effect@4.0.0-beta.78.patch — which already customizes this same pinger for connection hooks) so makeProtocolSocket/layerProtocolSocket actually accept those options. makePinger gains a configurable ping interval and pong deadline with a per-ping generation guard; defaults stay 5s/5s so no other caller changes behavior. (The review bots correctly caught that stock effect@4.0.0-beta.78 doesn't support these options — see the resolved threads.)

Rationale for the values:

• 20s pong deadline tolerates the server stalls that are currently killing connections, while a genuinely unreachable host is still detected within ~30s worst case.
• 10s ping interval keeps keepalive traffic frequent enough to hold NAT/firewall conntrack state on LAN/tunneled setups.
• Real disconnects are unaffected: a TCP close/reset still surfaces instantly through the socket close event — the heartbeat only matters for silently-dead paths and (today) for false positives on slow-but-alive servers.

I intentionally did not re-enable protocol-level retry (retryTransientErrors) — supervisor-owned reconnection from #2978 seems like the intended design, and transparent socket retries underneath it would fight that. This change just stops the supervisor from being invoked for stalls that aren't actually failures.

Testing

• vp run typecheck and the full client-runtime suite pass (37 files, 260 tests).
• Heartbeat configurability runtime-verified against the reinstalled patched package with a raw ws server: pingInterval: "1 second" produced 10 pings in 11s (vs 2 with defaults), and the pong deadline fired at interval+timeout (4.0s configured vs 10.0s default).
• Verified on the setup that reproduces [Bug]: I keep getting failed to connect. My PC did not respond with a connection setup. It's pretty annoying. Why does it do that. #3746 — a Windows 11 host on a LAN, with a patched build (this branch) served on a second port next to the regular 0.0.28 install, so clients could be compared against the same host at the same time:
  • 0.0.27 desktop client (macOS) → stable, as expected (old self-healing transport).
  • 0.0.28 desktop client (Windows) → repeatedly hit the reconnect loop with "… did not respond during connection setup" — the exact [Bug]: I keep getting failed to connect. My PC did not respond with a connection setup. It's pretty annoying. Why does it do that. #3746 symptom — against the same server the other clients were fine on. (It settled once the host quieted down, consistent with the failure being load/latency-triggered.)
  • Patched web client (this branch, served to browsers on both machines) → held its connection throughout, including during agent turns and repeated tab-away/tab-back cycles, with zero disconnect popups over multi-hour use.

If the team prefers different ping values or wants this configurable, happy to adjust — I kept the diff minimal on purpose.